home *** CD-ROM | disk | FTP | other *** search
/ Power Hacker 2003 / Power_Hacker_2003.iso / Exploit and vulnerability / hoobie / in.comstat.txt < prev    next >
Encoding:
Text File  |  2001-11-06  |  2.5 KB  |  47 lines
  1.  
  2. In the continuing saga of UDP ports sitting open on a machine, in.comsat
  3. can be exploited to cause some pretty nasty problems.
  4.  
  5. For the uninitiated, in.comsat allows users who have set biff y to recieve
  6. notification of new mail messages in their mail spool.  By sending UDP
  7. datagrams to port 512, in.comsat is started and breaks up the contents of
  8. the datagram.  The data sent is of the format "username@linenum" where
  9. username is the user who is recieving mail, and linenum is the location in
  10. the mail spool where the new mail resides.  Therefore, sending 'root@0' to
  11. port 512 will tell comsat to alert the user root that there is new mail,
  12. and it'll echo up the first couple of lines (7 lines or 560 chars, I
  13. believe) to the user's screen if A) they're logged in, and B) have biff
  14. set to y.
  15.  
  16. Now, the problem occurs when comsat fork()'s off (about line 221).  It
  17. does this so it can handle multiple user mail reports in a single comsat
  18. connection.  Unfortunately, if you feed a huge number of username lines
  19. very quickly to the open comsat, it'll continue to fork() off things
  20. (which die quickly).
  21.  
  22. As many of you can figure out from here, this can be exploited very easily
  23. over a LAN or from the local host.  For instance, if you have instated
  24. process quotas to prevent users from forkbombing your machine, they can
  25. simply start up a few "yes 'root@0' | nc -u localhost 512 &" (which will
  26. allow them to run quite a few things before running out of process space),
  27. but will open up a large enough stream of garbage to comsat to make it
  28. fork() off ad infinitum.  On my Linux machine, 3 or 4 of these open
  29. comsats is enough to make my system load hit >20.
  30.  
  31. Even if each fork()'ed process lasts for a short time, there is still
  32. enough bandwidth over a 10Mbps LAN (or T3 for that matter) to cause a
  33. machine to run out of PID's, or force the system load to climb higher and
  34. higher until it crashes.
  35.  
  36. Also, comsat does *NOT* log what is sent over the comsat connection unless
  37. there is invalid data, such as the user doesn't exist.  Otherwise, the
  38. only log entry is a single "in.comsat[PID]: connect from hostname".  If
  39. you do this from localhost, ESPECIALLY if it is preceded by some sort of
  40. mail delivery (perhaps just fake a mail to somewhere on the machine, or
  41. use the fun remote syslogging bug that we've all seen to fake a sendmail
  42. connect), there is very little to indicate foul play.
  43.  
  44. Solutions?  Well, either A) prevent comsat from fork()'ing (only allow it
  45. to handle 1 line at a time) or B) disable comsat all together.
  46.  
  47.